Recovering a project

This section describes how to recover a project from a problematic situation that might occur when master and replica servers are exchanging data.

• Recovering a project
• When a replica server is lost
• When the master server is lost
• When update packet from replica to master is lost
• When update packet from master to replica is lost

When a replica server is lost

In this scenario, the current state of a replica server is lost due to a system failure, and the replica server is restored from a backup file. The consequences are:

• If an update was sent to the master after making the backup, local changes made after the last update file was sent to the master are lost. Otherwise, local changes made after creating the backup are lost.

• Temporarily, the replica does not contain any master updates from the time after the backup was made. This is fixed when updates are exchanged again.

• If an update was sent to the master after making the backup, the local changes from the period of time after the backup was made and before the last update was sent to the master are only stored at the master. This is fixed when updates are exchanged again; the replica will then receive its old updates because they have master IDs newer than the replica's master update stamp. The objects should not be changed locally before receiving an update.

• The replica and master may have different information about the ownership of objects.

  • If the replica requested ownership before making backups and the master received the update, the replica thinks it has requested the ownership. If the master gave ownership to the replica, the next update will transfer the correct state to the replica. However, if the request failed, the replica will not receive an update unless the object has taken part in another transaction. We do not provide an automated solution to this special case. Instead, users must recognize the situation and modify the object at the master to resolve the inconsistency.
  • If the replica relinquished ownership after the backup was made and the master received the update, the replica incorrectly thinks it still owns the object. When the replica receives updates from the master it will get the object's correct state. The object must not be modified before receiving updates from the master; any local changes will be lost. The master checks that a replica owns all objects it tries to update. If an object is not owned, its current state is returned.

When a replica is restored from a backup, it is important that the databases are synchronized (that is, that updates are exchanged with the master) before any new local updates are done. The replica should refuse all local changes before a master update has been received.

When the master server is lost

In this scenario, the current state of the master server is lost due to a system failure, and the master server is restored from a backup file. The consequences are:

• All changes made at the master after creating the backup are lost. If updates were sent to replicas after creating the backup, the replicas may have newer versions of some objects. However, the replicas cannot send the new versions back to the master. Also, objects created after making the backup may appear only at replicas. There is no easy way to resolve the situation. For individual objects, it is possible to do the following operations at a replica: Request ownership, Check Out, Check In, Relinquish Ownership. After this, the master should have the newest copy. If the object does not exist at the master, it is not possible to use the normal interface for requesting ownership. Instead, this must be done by manually editing a backup file at the replica.

• The master and replicas may have different information about the ownership of objects.

  • If, after making the backup, the master gave ownership of an object to a replica and the replica has received the update, the replica thinks it is the owner while the master thinks that it is not. This situation is resolved only after the object is modified (or its status changes) at either the master or the replica. If modifications were done at the replica, they are lost.
  • If, after making the backup, a replica relinquished ownership of an object and the master received an update, the replica thinks it is not the owner while the master thinks it is. The solution is that the replica makes another ownership request; this request is accepted at the master and the replica will be notified of the new status.

When update packet from replica to master is lost

In this scenario, an update packet created at a replica server is lost. The replica remains in a state where it knows that an update has been sent but the reply has not been received from the master. In this situation it is possible to recreate the update packet. However, the new update packet is not identical to the lost one as it also contains the changes made after the original update was created.

If both the original and the re-created packet are installed at the master, problems can occur if there is an update that contains a modified object whose ownership was relinquished. Two packets will be created for the replica. The replica should only accept one.

When update packet from master to replica is lost

A replica update packet is created when a master update packet is installed at the master. If this packet is lost, the master cannot recreate it. Instead, the master update packet must be installed again. If the packet has been deleted, it must be recreated.